Remember that any need for frame rate higher than 100 Hz was eliminated in test patch U7.

Quote from Scawen :

...

About the connection between visual frame rates and force feedback:

In the old system there was a reason to go for higher frame rates to get more immediate force feedback. But this is now controlled by these user settings and there should be no reason to go higher than 100 fps (LFS physics update rate).

Quote from Aleksandr_124rus :

Do you have accepted decision about this?

I read through the whole thread a couple of days ago to check what people said. I've been working on the incompatible changes along with the compatible ones. So we aren't very far away now. I'm hoping that we can test incompatible changes next week.

On tyres and steering lock so far:

I've changed the tyre limits so that:

- Single seater racing cars can now use ROAD_SUPER tyres
- GTR cars can use ROAD_SUPER, ROAD_NORMAL, HYBRID and KNOBBLY tyres

I haven't tried the steering lock changes yet, so I can't say what will happen. I think I will first try increasing the limit to 60 degrees for the RWD cars, excluding single seaters, then look at each one to see if any problems come up. I don't plan to increase the steering lock for cars with driven front wheels as it's really impossible.

I wanted to start looking at this today before I replied, but something else I'm working on has taken longer than expected.

Yeah, there's only so much I can deal with. At some point I have to stop taking things on when the light at the end of the tunnel seems to be getting further and further away!

OK, some more updates in U15. Still a compatible version.

F12 pit instructions:

Pressure change with new tyre no longer counts as SETUP CHANGES
A new 'cancel' option beside the 'setup changes requested' line
Settings that will be adjusted are now shown in light red colour
FIX: rear tyre pressure was limited by front tyre pressure limits
FIX: symmetric pressure/camber request remained after pit stop

Multiplayer:

More accurate transmission of fuel load from local to remote car
Remote car fuel load is now shown in F12 if /showfuel is enabled
Rolling resistance included in catch-up phase of prediction
FIX: Remote cars with worn tread could wrongly get a puncture

Misc:

Auto-repeat key function reinstated (disabled in previous test)
MPR / SPR are now prevented from being named temp_mpr / temp_spr
Free view mode minimum field of view reduced from 10 to 2 degrees
InSim NLP / MCI minimum time interval reduced to 10 ms (was 40 ms)
Mouse X and Y sensitivity (in Axes tab) lower limit reduced to 0.5
FIX: Message MPR_BLANK sometimes displayed when watching live MPR

https://www.lfs.net/forum/thread/93185

OK, some more updates in U15. Still a compatible version.

F12 pit instructions:

Pressure change with new tyre no longer counts as SETUP CHANGES
A new 'cancel' option beside the 'setup changes requested' line
Settings that will be adjusted are now shown in light red colour
FIX: rear tyre pressure was limited by front tyre pressure limits
FIX: symmetric pressure/camber request remained after pit stop

Multiplayer:

More accurate transmission of fuel load from local to remote car
Remote car fuel load is now shown in F12 if /showfuel is enabled
Rolling resistance included in catch-up phase of prediction
FIX: Remote cars with worn tread could wrongly get a puncture

Misc:

Auto-repeat key function reinstated (disabled in previous test)
MPR / SPR are now prevented from being named temp_mpr / temp_spr
Free view mode minimum field of view reduced from 10 to 2 degrees
InSim NLP / MCI minimum time interval reduced to 10 ms (was 40 ms)
Mouse X and Y sensitivity (in Axes tab) lower limit reduced to 0.5
FIX: Message MPR_BLANK sometimes displayed when watching live MPR

https://www.lfs.net/forum/thread/93185

Quote from Eclipsed :

So the suggestion is that either switching back to assymetric it should return to previous settings or there should be some way to cancel requested setup changes.

I missed the final part of your suggestion yesterday but came to the same conclusion today.

It was an easy fix to cancel all requested changes in F12, because the unchanged setup is available in the current car setup. So the 'cancel' option will be in the next (compatible) test patch.

Quote from MandulAA :

About setup changes in pitstops, this thread might be related (I'm not sure): https://www.lfs.net/forum/post/1960373#post1960373

Actually that is different - I fixed that one yesterday and that was just about the rear tyre pressure using front tyre limits. It will be in the next (compatible) test patch.

Quote from KevinRacer :

In bf1 I think I have encountered a similar bug. I guess "setup changes needed" remains as long as the setup after changes is different from the starting setup.

It's supposed to only say that if the requested setup changes are different from the current setup. Anyway I can reproduce it 100% (the symmetrical setup thing) so I'll be able to fix it.

Maybe I'd better reinstate auto-repeat!

By the way, I've been working on pit stops - a compatible change and an incompatible change. I found a bug that I can reproduce in the existing test patch. Is it a well-known bug?

I took FOX on FE1. Using default setup, do a lap and set front tyre pressure to be adjusted (leaving it symmetric). Enter pits, there is "setup changes" as expected and drive away. Now the bug is that "Setup changes requested" remains set although you can't see any changes requested. Next pit stop there are "setup changes" again although you haven't changed anything. I think it's related to the 'assymetric' setup (although the setup is set as symmetric so you can't see that).

Quote from Pasci :

Under certain circumstances, the outsourcing of AI drivers to the dedicated host would be a better solution than increasing the permitted number on the client side? It would be good if you could determine the "field size" and as soon as a real driver connects, the number of AIs is "dynamically" reduced (or increased if someone disconnects from the host).

AI on server would be good but our current DCon can't possibly do that, as it only has a very cut-down version of the tracks, not including the physical surfaces. It doesn't need them because it doesn't run physics. It is already possible with a full version of LFS running as the server but that requires a user name. A full version can run in 'dedicated' mode but currently runs in the same way as DCon. I think that option could be made to run physics but it's really beyond the scope of this minor update.

I only started this process to allow a wider range of settings. It's turned into a multiplayer prediction + various other things but I still want to get this done ASAP because there is a lot still to do in the development version.

Quote from THE WIZARD DK :

1. could this have had impact on the shifting thing?
2. i am using space bar with keyboard. will that be customizable?
or SPACE only?


also. i tried to go in single player mode.
with 21 cars (all types) and myself on track i still get those lagspike things at some times.
you asked me if i got that recently. it seems i do. patch u13. what can cause this then?

No, the packet sending rate due to speed limiter was only related to packets.

The space bar for VR click is not customisable and I don't have any plans to do so. This code was designed so that space bar when typing no longer interferes with VR click, for people with a VR headset.

I don't know why you have lags but I don't think it's related to this test patch. If it is to do with graphics card limitations (memory swapping) you could try lower texture resolution. Otherwise lags could be caused by other programs running on your computer.

Test Patch U14 is now available.

I've been working on things to improve the prediction but they are mainly incompatible, so not included in this test patch.
This patch contains some compatible updates while I continue trying to improve the prediction system.

Changes from 0.6U13 to 0.6U14:

Multiplayer:

Command /showfuel (no/yes) allows remote car fuel load to be seen
Most admin commands with parameter omitted report current value
FIX: Car on pit speed limiter sent maximum packets per second
FIX: Remote car's tyre temperature over 200 appeared black (cold)
FIX: Remote tyre temperatures increased too slowly in skid or spin

MPR debug commands:

/mprlag X simulates online packet delay of X ms (+ no smoothing)
/mprsmooth X (0 or 1) to disable or enable input smoothing

CPU usage display:

In Graphics or Misc options (in-game) click the car icon then 'P'
You can now see CPU usage for Physics, Draw, Prediction, etc.
The "Pred" line shows CPU usage for prediction of remote cars
Prediction time also shows up in an MPR if /mprlag is set

Support for live multiplayer replays:

Replay identified as live when starting to watch an unfinished MPR
Does not exit replay after fast forwarding to current time
Catch up to live position by clicking >| button
Skins can be downloaded while watching a live replay
Save replay while temp_mpr is being viewed - copy instead of rename
Start new mpr while temp_mpr is in use - tries temp_mpr_1 (up to 9)
/mprflush X to flush mpr to file every X seconds (0 = disable)

VR:

Virtual keyboard is shown at dialog height if no dialog is visible
Space bar VR click auto disabled when you type with real keyboard

Misc:

Increased distance for car subobjects to become invisible
FIX: Free view roll is now reported in InSim IS_CPP packet

https://www.lfs.net/forum/thread/93185

U14 is now available.

I've been working on things to improve the prediction but they are mainly incompatible, so not included in this test patch.
This patch contains some compatible updates while I continue trying to improve the prediction system.

Changes from 0.6U13 to 0.6U14:

Multiplayer:

Command /showfuel (no/yes) allows remote car fuel load to be seen
Most admin commands with parameter omitted report current value
FIX: Car on pit speed limiter sent maximum packets per second
FIX: Remote car's tyre temperature over 200 appeared black (cold)
FIX: Remote tyre temperatures increased too slowly in skid or spin

MPR debug commands:

/mprlag X simulates online packet delay of X ms (+ no smoothing)
/mprsmooth X (0 or 1) to disable or enable input smoothing

CPU usage display:

In Graphics or Misc options (in-game) click the car icon then 'P'
You can now see CPU usage for Physics, Draw, Prediction, etc.
The "Pred" line shows CPU usage for prediction of remote cars
Prediction time also shows up in an MPR if /mprlag is set

Support for live multiplayer replays:

Replay identified as live when starting to watch an unfinished MPR
Does not exit replay after fast forwarding to current time
Catch up to live position by clicking >| button
Skins can be downloaded while watching a live replay
Save replay while temp_mpr is being viewed - copy instead of rename
Start new mpr while temp_mpr is in use - tries temp_mpr_1 (up to 9)
/mprflush X to flush mpr to file every X seconds (0 = disable)

VR:

Virtual keyboard is shown at dialog height if no dialog is visible
Space bar VR click auto disabled when you type with real keyboard

Misc:

Increased distance for car subobjects to become invisible
FIX: Free view roll is now reported in InSim IS_CPP packet

https://www.lfs.net/forum/thread/93185

Thank you all for these results and observations.

It's hard to know how the CPU usage is really being affected by the prediction. I will look and see if I can add a CPU usage timer that can display CPU usage for Physics and Prediction separately. If I could make this visible on screen at the side, then we could get more of an idea how badly Turn One mayhem is affected by increased packet rate in conjunction with high ping.

The other thing is a prediction issue that seems worst with the BF1. I don't think it's anything unique about the BF1 - it's probably just the most extreme example. I get the feeling that it is not only related to speed. I think it may be something to do with tyre deflection. Suspension deflection is included in the position packet but lateral tyre deflection is not. So I think for the first frame of prediction, forces on the car are too small and it takes a couple of updates to build up the tyre forces. It's only a theory. Unfortunately it would need a larger position packet and that can't be done in a compatible version but I'll have a look. We want to do an incompatible version anyway but we're a few days from that as there are still compatible updates to do. Anyway I can test locally at first.

I think we also need an option to watch MPRs without the steering smoothing, so it's a better representation of what we see online. Don't know if I could add a bad ping simulation to it as well.

Quote from Degats :

Looking at several replays, it appears that the smoothing is still working properly when watching replays in U13 only if the car you're watching was also on U13, but not if they were on older versions.

That's a good observation. For some reason which I can't remember, the program does an estimate of when the next packet will arrive. U13 uses the U13 next packet time calculation so that explains why the U12 ones move too quickly then stop. I'm not sure why it was easier to do it that way rather than using a real packet time.

Thanks, maybe you can suggest they try the U13 test patch if possible?

Most benefits will come from the use of the patch.

DCon only allows the max pps up to 12 but most of the time that doesn't affect anything.

Quote from nexttime :

So your own car in a mpr is always 6pps even if the server is set to 4 or something? Or 12 in this case. Because in some of my own replays (6pps version) I see a lot of glitches sometimes on my car.

How it works is: Any MPR stores all the network packets that are sent (as long as they are received).

So if there is a good connection, an MPR stored on player A's computer should look identical to the MPR stored on player B's computer. As you can see in kagurazakayukari's video, the MPR from both computers is mostly identical, other than a few points where some packets got lost.

So you can actually test the effect of the packet rate by saving an MPR locally.

But there are two things different in an MPR:

- In an MPR, prediction time is only the time between two packets. Live online prediction time is the time between two packets plus the delay between the packet being sent on the driver's PC and received on the observer's PC.

- In an MPR, inputs can be smoothed between one packet and the next which helps make the prediction a bit better.

Quote from nexttime :

So your own car in a mpr is always 6pps even if the server is set to 4 or something? Or 12 in this case. Because in some of my own replays (6pps version) I see a lot of glitches sometimes on my car.

No, that's not how it works.

Quote from nexttime :

In LFS everybody has that glitch regardless of their ping, either always or somewhere on the track.

Well I released a patch yesterday that should have improved that quite a bit for people with good ping. I haven't had a lot of feedback about the results yet.


EDIT: That's not a complaint - it's not an easy thing to test so may take time. And the person who downloads the test patch isn't the one who will see the results. It's the other people who should see their car glitching less. Best results are when driver and observer both have the new version, because the steering glitch reduction is at both ends (that is a separate feature from the extra packets).

One possible test would be to observe two people with equally good ping, driving on a flat surface, maybe slaloming gently left to right in sync with each other, in the same car. One driver has U13 and the other driver has U12 or earlier. The observer should have the new version. The result of the test should be visible in the MPR.

Actually there doesn't really need to be a live observer, only the two drivers. The 'observer' could be anyone who watches the MPR later.

Last edited by Scawen, Tue 12 Jan 2021, 20:37.

The Wizard DK: I've moved your posts about shifting to a new thread in technical assistance because it's not related to the test patch.
https://www.lfs.net/forum/thread/94955

Did you get those messages with the previous version of LFS, or only with the test patch?

Test Patch U13 is available.

It's intended as a moderate improvement. I have tried to increase packet frequency carefully where it is needed, while making sure it is never decreased. The idea is to reduce glitching but without causing the negative effects that could come from packet overload.

I'm not saying it's perfect or the best it can be, but I believe it is noticeably better, after 1.5 days' work.

Where I say "sender" below I mean the local computer where a car is being driven. When I say "receiver" I mean someone observing that car on a remote computer.


Multiplayer:

Reduced steering glitch each time a position packet is received
- this requires the sender and receiver to have the new version

Position packets are sent more frequently in response to steering
- packet frequency is further increased at higher speeds
- this requires only the sender to have the new version

Maximum packets per second (/pps) has been increased to 12
- this doesn't change much except in specific circumstances
- FIX: /pps command while in multiplayer was not sent to guests
- this requires only the server to have the new version

https://www.lfs.net/forum/thread/93185

Test Patch U13 is available.

It's intended as a moderate improvement. I have tried to increase packet frequency carefully where it is needed, while making sure it is never decreased. The idea is to reduce glitching but without causing the negative effects that could come from packet overload.

I'm not saying it's perfect or the best it can be, but I believe it is noticeably better, after 1.5 days' work.

Where I say "sender" below I mean the local computer where a car is being driven. When I say "receiver" I mean someone observing that car on a remote computer.


Multiplayer:

Reduced steering glitch each time a position packet is received
- this requires the sender and receiver to have the new version

Position packets are sent more frequently in response to steering
- packet frequency is further increased at higher speeds
- this requires only the sender to have the new version

Maximum packets per second (/pps) has been increased to 12
- this doesn't change much except in specific circumstances
- FIX: /pps command while in multiplayer was not sent to guests
- this requires only the server to have the new version

https://www.lfs.net/forum/thread/93185

Last edited by Scawen, Mon 11 Jan 2021, 18:50.

If anyone would like more information about the current work on prediction and packet frequency, here are a few posts on the test patch thread.
https://www.lfs.net/forum/post/1961950#post1961950

Quote from MicroSpecV :

Just as a reference on why we need to focus on having better pps and refresh rates.... well, it was not a pretty opening corner for GT2c yesterday.

Thanks for the reference video but the rest of your post is basically antagonistic, irritating and factually incorrect.

Maybe you've missed the updates in the test patch thread.

This is not about 'pps' as I keep saying but it goes over the head of people all the time. The issues involved are far more subtle.

Petrol makes cars go, right? So if my car is broken I can pour petrol over it to fix it, right? No, that is wrong. So dear people, please stop saying that more and more packets per second will solve everything. It won't.

Also, MicroSpec, I'm here working all yesterday and today looking into how to improve the predictions. So telling me my code is 'trash' because you have a terrible ping is not helpful. Also your advice that we shouldn't be prioritising tyre choices is entirely irrelevant, because that is something you've made up, and has nothing to do with what is actually happening.

A small update 'U13' for the dedicated host (DCon) is attached.

It allows /pps 12 in internet multiplayer mode.

I don't think it makes much difference, as it is only an upper limit on "position packets per second" but in some situations it could help. It will *not* cure the problems of latency and can make some problems resulting from latency even worse (namely CPU usage on your local computer during the 'catch up' from when the packet was sent on the remote computer, to the current time).

The previous maximum was 6.

The command /pps X was found not to be working to change pps while already running but it does now work and there is a message on guest computers when the resulting packet is received.

This is a compatible update.

EDIT: removed attachment, it's now the official test patch.

Last edited by Scawen, Mon 11 Jan 2021, 18:52.

Thanks for the feedback.

Quote from rattijonni :

Increasing the miniscule 6pps in multiplayer to atleast 12 should also be an easy and worth while change.

I was wondering about this often requested change. As usual I fear it may make things worse. I believe it can help when all players are near the server, with minimal lag. In this case it can bring similar benefits to using a high pps on a LAN. The problem I have with it is that the really bad lagging you see is usually from players with high latency (time lag to the server).

Higher pps cannot help with this. Such players, if sending twice as many packets per second, will not appear any better to the other players and will still be all over the place. Only now they will consume more CPU on the other players' computers because of the catch-up physics done on each position update.

So the problem is that more packets per second cannot possibly solve the worst problem and could make it worse. Turn 1 slowdowns could become a slide show of carnage.

I feel it's a bit like having a broken cylinder head gasket and increasing the turbo boost to try to get some more power to compensate.

But I can see that it could be worth a test. Maybe I can even run a local multiplayer test here using a remote server to get an initial feel for it before trying it in public.

Quote from tankslacno :

Small question related to that AI-thing: since it requires us to connect to online to test it, could we test this patch on hosts rented on LFS.net or is the only way to test this is to download a Dedi host for that patch or start a new server from LFS itself?

Good question, I'll need to ask Victor about this.


Other comments - thanks for the feedback. I'm reading and thinking...

NOTE: This is about a quick update of the existing version. Nothing to do with the major changes in the development version.

Hello Racers,

A test patch has been in use for a long time and some people would like it to become official.

I would like to ask about a few small changes which are easy and safe to introduce, but would make the version incompatible online. So if they are done, they should be tested for the minimum time before becoming official.

I've been asked a few times about increasing the number of AI per player in multiplayer mode. This is easily done but I'm not that confident to allow the full number of 32 drivers per connection. I feel it's better to test in smaller steps but in this case maybe we could go up a lot from the current maximum of 3. How about to 24?

Some other changes have been requested, for the use of GTR cars for drifting and off-road.

Drifters have asked for the maximum steering lock to be increased and to allow the full range of tyres, for the XRR and FZR cars. We received a request to allow up to 65 degrees steering angle but it seems a bit much to me. Those two cars have double wishbone suspension so that seems to put a limit on the amount a wheel could turn before part of the wheel hits part of a wishbone with disastrous results. I don't have any real world reference for what maximum lock is achievable by drifters in real life.

About off-road use, I found a note from about 10 years ago suggesting to allow the off road tyres on the smaller GTR cars as they have some resemblance to rallycross cars and that could allow some fun racing. I've seen a recent request to allow the FXO GTR to use the off road tyres for rallycross.

So, combining the above two purposes it seems like it could be a good idea to allow the knobbly, hybrid, road and road super tyres on all the GTR cars, and to increase the allowed maximum lock on the XRR and FZR.

Reservations:

It might be a bit unrealistic, allowing such tyres on those cars. The big GTR cars are obviousy not designed for off road use, but if it allows more possibilities for drifting and racing, then it seems like a good thing to allow.

Steering lock being increased a lot, with wide front wheels on double wishbone suspension, might seem to defy reality a bit. But I'm interested to hear what you have to say.


P.S. What I mean by "semi-compatible" is that old hotlaps should still be valid if these lock and tyre choice limits were relaxed. But this new version could not connect with the old version online.

The same fix should be in 6U and any patch since. The LFSOpenVR.dll in 6U has a file date of 8 March 2019 which is only shortly after the one linked 3 posts up. It should give the same results. There shouldn't be any relevant changes in the U12 version that would affect this.

I don't think anyone else has mentioned the HP Reverb except for Ross Burton in this post on the Test Patch thread:
https://www.lfs.net/forum/post/1952241#post1952241

In his case it seems to work well (although his post was before the latest version of the dll). I'd be interested to have a look in the openvr.log file if you attach it here. Sometimes there can be a clue in there. It appears in the LFS folder when you use an OpenVR headset.

EDIT: I see Ross Burton was using the old HP Reverb, not the G2 so it seems you are the first to comment about this headset.

Last edited by Scawen, Sat 2 Jan 2021, 16:37.

Hi, sorry but that is not possible at the moment, as there can only be 3 drivers per computer. So with two computers that is a maximum of one real driver plus 5 AI.

I do have a note for the request to allow more cars per computer as it has been requested a few times. I don't think it is really difficult but it would be an incompatible version as changes are needed on guest and host side.

I'm considering the possibility of a new incompatible version with this change and also a small change to allow more maximum lock on FZR and XRR for drifters.

The problem with incompatible updates is they divide the community between official version users and test patch users so it's important to keep those testing stages as short as possible.

Also I have to keep such updates as safe and minimal as possible because there is so much work to do on the separate development version.